Description

The Controller Language is free format. A command does not have to be completed on a single line. It does not matter where the command begins, i.e. it does not have to start in column 1. In order to make the program as readable as possible, however, it is a good idea to follow a format guideline. There are many differ- ent conventions religiously defended by as many corresponding users. The chapter titled "Program Formatting" contains a particular format used by and encountered in the demo programs .Which conventions are followed does not matter however using some convention consistently does matter. Use whatever convention that is clearest.

Because commands can start on one line and end on another there is need to be explicit about where a command actually ends. Accordingly the end of a command or statement is indicated with a semicolon.

The language supports and invites the use of symbolic names. These symbols are used to represent the problem and the corresponding solution. The clarity of a program and its ability to be correctly written the first time, corrected, and maintained is dramatically effected by the choice of symbolic names. The proper description of a problem is half way to having a solution and much of the description occurs in the naming process of the operations and information in the program. If meaningfully names are hard to find identify this may be a strong indication and warning that the problem is not very well understood. There is no run-time penalty for lengthy variable names. There is no merit to long names for the sake of simply being long however long names are sometimes required in order to be clear. The best method of keeping tight correspondence between documentation about a program and the program itself is to have the program be self-documenting, i.e. writing the program with such expressive symbol naming that to read the program is to read a description of the program.

The language allows symbols to be up to 60 characters long. Symbols are generally composed of letters, numbers, and the underscore character but should not contain other characters (i.e. no spaces). There is no distinction made between capital and small letters. One symbol naming school of thought is to have multiple word symbols separated by the underscore as if it was a space, for example:

drill_head_home_position

Another school of thought is to use capitalization to emphasize where a new word begins, for example:

DrillHeadHomePosition

The second approach is used for predefined objects and methods in the language so your program may appear more consistent using the second method. Either choice is fine.

Another industrially encountered convention used by the language is a capital ?T? before symbols that are type definitions, i.e. the predefined 4 dimensional vector type is called ?T4Vector?. The leading capital T is a clue that the symbol has something to do with type definitions. Again this is optional but you may choose to con- form to the standard for the sake of consistency.

The language supports curly bracket comments. Anything inside curly brackets is disregarded and may be used to provide notes to describe the nearby program. Comments are not nestable, i.e. the one thing a comment cannot contain is another comment. The following program fragment indicates how a comment might be used: